Before allowing a person to access a sensitive computer system or application (and the data it manages), it is well known and common for the computer system or application to authenticate the person and if the person is authentic, check whether the person is authorized to access the computer system or application. Typically, authentication is based on a valid combination of User ID and password provided by the person. Typically, authorization is based on an Access Control List maintained by the computer system or application. The Access Control List lists the User IDs which are authorized to access the computer system or application (and the data it manages).
Different applications and files within a computer system may require different “levels” of access. The highest level of access to the most sensitive applications and files is typically called “root” access (or administrator access). Typically, root access is reserved for administrators, and allows the administrators to execute the most sensitive applications and change the most sensitive files. Examples of applications that typically require root access are mount, passwd. Examples of files that typically require root access are /etc/passwd, /etc/group, /etc/shadow. Users typically have the lowest level of access, called “user” access, and this allows the user to use less sensitive applications and access less sensitive files. In some cases, root access is required to change a file, such as a /etc/fs or /etc/passwd configuration file, but user access is sufficient to read the same file.
Some Ds and passwords are created and used by respective individuals. Other Ds and passwords are assigned to and used by a group of people. Most security policies require that passwords be changed periodically, such as every six months. This limits unauthorized exposure of the sensitive application or file if a hacker learns a valid combination of User ID and password of an authorized person or group. In the case of individual User IDs and individual passwords associated with respective individuals, the user changes his or her password periodically as required by the security policy. In the case of a “group” User ID and password, it is common for one person in the group to periodically change the password, according to the security policy.
It was known to allow a person to obtain a new password for a system or application before expiration of the current password by the person entering the person's current password.
It was known to allow a person to obtain a new password for a system or application after expiration of the current password by the person entering the person's expired password.
It was known to allow a person to obtain a new password after expiration of the current password by the person entering a User ID and the authentication system sending the new, system generated password to an e-mail address previously registered for the User ID. Next, the person can enter the system-generated password along with a new person-generated password to substitute the person-generated password for the system-generated password.
Often, the person forgets the person's current or expired password. In such a case, it was known to allow such a person to reset the person's current or expired password by a challenge/response process. In this process, an authentication program poses a series of challenges or questions to the person, such as requests for the person's mother's maiden name, the name of the street where the person grew up, etc., in addition to the person's User ID. (The person provided the answers to the challenges or questions upon original registration.) If the person answers the questions properly, then the system allows the person to obtain a new password for the current User ID. A typical challenge/response process to obtain a new password is not as secure as requiring the current or expired password to obtain a new password. This is because the typical challenges/responses, while not widely known, are not secret and are not protected as secrets.
As explained above, in the case of a group User ID and group password, typically one person in the group (a “super administrator”) changes the group password periodically (by furnishing the current or expired password for authentication) as required by the security policy. For a large computer system with a large number of computers, applications and files, there may be a large number of administrators (up to one hundred), each requiring root access. In such a case, each time the group password is changed, the person who changed the group password sends the group password electronically (such as by e-mail) to each administrator, and each administrator typically makes a record of the new password. There have been difficulties in ensuring that each administrator (a) receives the new group password, and (b) if received, retains a copy of the password in a secure manner.
An object of the present invention is to better control distribution of group passwords to authorized users.